The present invention generally relates to computerized financial/accounting systems. More particularly, the present invention relates to utilizing supporting dimensions to further define transaction entities in a financial/accounting system.
Computerized financial systems and programs (i.e., software applications) are configured for use by both accountants and non-accountants. These systems allow users to set up various types of accounts such as general ledger, inventory, order entry, accounts receivable, accounts payable, bank manager, and payroll accounts. Each account, or account module, of the accounting system are typically fully integrated and share common data. As a result, a transaction can be entered, for example, as an invoice, and the accounting system automatically performs the necessary credits and debits on the affected accounts including posting the transaction to the general ledger without requiring the user to reenter any data. Thus, such computerized accounting systems are ideal tools for the non-accountant user. Additionally, they save time, reduce the likelihood of errors, and eliminate the need to reenter data for posting to the general ledger.
The general ledger maintains a list of posted transactions relating to all of the accounts of the system. As is well known for double entry bookkeeping systems, valid accounting transactions include a debit component and a credit component where the absolute value of the debit component is equal to the absolute value of the credit component. The general ledger module typically maintains the summary information of the transaction histories and balances for all of the accounts of the system, while the individual account modules maintain more detailed historical transaction data and balances for their respective accounts. In the general ledger module and the other account modules, individual entries or records relating to a transaction are, in general, referred to as transaction entities.
In a typical accounting system, in addition to an account number, date and an amount, a transaction entity usually includes information that further defines the entity. For example, a transaction entity for ticket sales at an event can include an event code and a visitor code (to further define the transaction entity) in addition to an event date, an account number, and an amount, which constitute the “core” of the transaction information. Valid event codes and visitor codes are predefined and stored in the financial system. Thus, a user entering ticket sales transactions is restricted to entering/selecting and saving only predefined event and visitor codes to further define the sales transactions. Such additional pieces of information or dimensions, that are predefined and selected on the transaction, are referred to as “standard” dimensions. Using only standard dimensions to further define transactions helps maintain data integrity within the financial system. However, such constraints do not allow a user to enter/track additional non-predefinable data, related to the transaction, such as a quantity (for example, in a ticket sales transaction, the number of people who attended a particular event), which may be useful for analytical purposes.